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[57] ABSTRACT 

In summary, the present invention is a multithreaded com- 
puter system having a memory that stores a plurality of 
objects and a plurality of procedures. Each object has a lock 
status of locked or unlocked, and includes a data pointer to 
a data structure. The system uses a global object locking 
procedure to service lock requests on objects that have never 
been locked as well as objects that have not recently been 
locked, and uses a local object-specific locking procedure to 
service lock requests on locked objects and objects that have 
been recently locked. The global object locking procedure 
has instructions for changing a specified unlocked object's 
lock status to locked, and for creating for each specified 
object a local object locking procedure. The local object 
locking procedure includes a lock data subarray for storing 
the object's lock data and instructions for updating a speci- 
fied object' s stored lock data. A lock data cleanup procedure, 
executed when the system's garbage collection procedure is 
executed, releases the local object locking procedure of a 
specified object if the object has not been recently locked. 

23 Claims, 6 Drawing Sheets 
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SYSTEM AND METHOD FOR SPACE overhead for frequently used object, and that uses storage 

EFFICIENT OBJECT LOCKING USING resources that are proportional to the number of locked 

GLOBAL AND LOCAL LOCKS objects. 

_ . . . ^ - r ri « SUMMARY OF THE INVENTION 

This application is a continuation-in-part of application 5 

Ser. No. 08/569.753 filed Dec. 8. 1995. In summary, the present invention is a multithreaded 

The (resent invention relates generally to object-oriented computer system having a memory mat stores a plurality of 

computer systems in which two or more threads of execution objects and a plurality of procedures. Each object has a lock 

can be synchronized with respect to an object and particu- status of locked or unlocked. There are two ways objects 

larly to a system and method for efficiently allocating lock io may be represented, either as a handle consisting of a data 

data structures in a system where most or all objects are pointer to a data structure and methods pointer to a methods 

lockable, but relative few objects are in fact ever locked. array, or as a direct pointer to an object data structure, the 

first element of which is a methods pointer to a methods 

BACKGROUND OF THE INVENTION myt For ^ purposes of the present invention, this repre- 

In multiprocessor computer systems, software programs 13 sentational difference is not significant, 

may be executed by threads that are run in parallel on the In cither case, the methods array includes lock and unlock 

processors that form the multiprocessor computer system. procedures for the object Each object is further an instance 

As a result, a program may be run in parallel on different of some class, and has a data reference, stored with its 

processors since concurrently running threads may be method array, to a class data structure associated with this 

executing the program simultaneously. Moreover, if a pro- 20 class. Two objects that are instances of the same class then 

gram can be broken down into constituent processes, such share this class data structure, having identical references to 

computer systems can run the program very quickly since it This class data structure includes a permanently allocated 

concurrently running threads may execute in parallel the class lock data structure associated with this class, which can 

constituent processes. Single processor, multitasking com- be used for synchronization of modifications to objects 

puter systems can also execute multiple threads of execution 25 which otherwise have no lock data structures associated with 

virtually simultaneously through the use of various resource them. 

scheduling mechanisms well known to those skilled in the The system uses a single global object locking procedure 

art of multitasking operating system design. as the lock procedure to service lock requests on objects that 

The programs run on such computer systems are often have not been allocated a lock data subarray (i.e.. objects 
object oriented. In other words, the threads executing the 30 that have never been locked and objects that have not 
programs may invoke methods of objects to perform par- recently been locked), and uses a local, object-specific 
ticular functions. However, some methods of some objects locking procedure as the lock procedure to service lock 
may be implemented only one at a time because of hardware requests on objects that have been allocated a lock data 
or software constraints in the computer system. For subarray (i.e., objects that are locked and objects that havr 
example, an object may require access to a shared computer 35 been recently locked), 
resource, such as an I/O device, that can only handle one The global object locking procedure has instructions for 
access by one thread at a time. Thus, since concurrently creating a local object locking procedure specifically for the 
running threads may concurrently seek to invoke such an object to be locked. The local object-specific locking pro- 
object the object must be synchronized with only one thread cedure includes as private data a lock data subarray for 
at a time so that only that thread has exclusive use to the storing lock data. The local object-specific locking proce- 
object (ie., only one the thread at a time can own a lock on dure has instructions for updating that object's stored lock 
the object). data. A lock data cleanup procedure, executed when the 

In the past, various approaches have been used to syn- system's garbage collection procedure is executed, releases 
chronize an object with a thread. These include the use of 4J the memory used for the local object-specific locking pro- 
synchronization constructs like mutexes. condition cedure if the object has not been recently locked, 
variables, and monitors. When using monitors, each monitor in a preferred embodiment, each object that has not been 
identifies the thread that currently owns the object and any allocated a lock data subarray has a methods pointer that 
threads that are waiting to own the object. However, in the references a set of procedures that includes the global object 
computer systems that employ these monitors there is often ^ Locking procedure; such objects are necessarily never in a 
a monitor for every synchronizable object As a result, this locked condition. Each object that has been allocated a local 
approach has the distinct disadvantage of requiring a large object-specific locking procedure has a methods pointer mat 
amount of memory. references a set of procedures that includes its local object- 

A simple approach to reducing the memory required by specific locking procedure. Furthermore, the global object 

these monitors is to allocate a cache of monitors and to 55 locking procedure includes instructions for updating a speci- 

perform a hash table lookup in this cache on each monitor fied object's method pointer to point to a set of procedures 

operation. Such an approach can substantially increase the that includes the local object-specific locking procedure, 

overhead of monitor operations, and the slow speed of this The lock data cleanup procedure includes instructions, 

solution led to the present invention. activated when a specified object's updated lock data indi- 

It is an object of the present invention to provide a object eo cate that the specified object has not been recently locked, 
locking system in which space is allocated for lock data on for changing the specified object's method pointer to point 

an as-needed basis so as to avoid the allocation of memory to a set of procedures that includes the global object locking 
resources for lock data structures for objects that while procedure. 

lockable. are in fact never locked. More specifically, in a preferred embodiment the corn- 
It is another object of the present invention to provide a 65 puter system includes a set of object classes, and each object 
lock data allocation system and method that is computation- class includes a virtual function table (VFT) that includes 
ally efficient and that imposes essentially no computational pointers referencing a set of methods associated with the 
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object class as well as a pointer that references the global 
object locking procedure. Each object that has not been 
recently locked has a methods pointer that references the 
VFT for a corresponding object class. 

For each object that has been recently locked, the system 
stores an object- specific virtual function table (VFT) that 
includes pointers referencing the set of methods associated 
with its object class as well as a pointer that references that 
object's local object locking procedure. The global object 
locking procedure includes instructions for creating the 
object-specific VFT and for updating a specified object's 
method pointer to reference its object-specific VFT. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Additional objects and features of the invention will be 
more readily apparent from the following detailed descrip- 
tion and appended claims when taken in conjunction with 
the drawings, in which: 

FIG. 1 is a block diagram of a computer system incor- 
porating a preferred embodiment of the present invention. 

FIG. 2 is a block diagram of the data structure for an 
object that has not yet been allocated a lock data subarray in 
a preferred embodiment of the present invention. 

FIG. 3 is a block diagram of the data structure for an 
object for which a lock data subarray has been allocated in 
a preferred embodiment of the present invention. 

FIGS. 4 and 5 are flow charts of the procedures for 
locking ao object in a preferred embodiment of the present 
invention. 

FIG. 6 is a flow chart of a preferred embodiment of a lock 
data cleanup method. 

FIG. 7 is a flow chart of an alternate embodiment of a lock 
data cleanup method. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

Referring to FIG. 1, there is shown a distributed computer 
system 100 having multiple client computers 102 and mul- 
tiple server computers 104. In the preferred embodiment 
each client computer 102 is connected to the servers 104 via 
the Internet 103. although other types of communication 
connections could be used. While most client computers are 
desktop computers, such as Sun™ workstations. IBM™ 
compatible computers and Macintosh™ computers, virtu- 
ally any type of computer can be a client computer. In the 
preferred embodiment each client computer includes a CPU 
105. a communications interface 106, a user interface 107. 
and memory 108. Memory 108 stores: 

an operating system 109; 

an Internet communications manager program 110; 

a byte code program verifier 112 for verifying whether or 
not a specified program satisfies certain predefined 
integrity criteria; 

a bytecode program interpreter 114 for executing appli- 
cation programs; 

a class loader 116. which loads object classes into a user's 
address space and utilizes the bytecode program veri- 
fier to verify the integrity of the methods associated 
with each loaded object class; 

at least one class repository 120, for locally storing object 
classes 122 in use and/or available for use by user's of 
the computer 102; 

at least one object repository 124 for storing objects 126. 
which are instances of objects of the object classes 
stored in the object repository 120. 



4 

In the preferred embodiment the operating system 109 is 
an object-oriented multitasking operating system that sup- 
ports multiple threads of execution within each defined 
address space. The operating system furthermore uses a 

s garbage collection procedure to recover the storage associ- 
ated with released data structures. The garbage collection 
procedure is automatically executed on a periodic basis, and 
is also automatically invoked at additional times when the 
amount of memory available for allocation falls below a 

10 threshold level. For the purposes of this document it may be 
assumed that all objects in the system 109 are lockable 
objects, although in practice relatively few objects are 
actually ever locked. 
The class loader 116 is typically invoked when a user first 

15 initiates execution of a procedure, requiring that an object of 
the appropriate object class be generated. The class loader 
116 loads in the appropriate object class and calls the 
bytecode program verifier 112 to verify the integrity of all 
the bytecode programs in the Loaded object class. If all the 

20 methods are successfully verified an object instance of the 
object class is generated, and the bytecode interpreter 114 is 
invoked to execute the user requested procedure, which is 
typically called a method. If the procedure requested by the 
user is not a bytecode program and if execution of the 

25 non-bytecode program is allowed (which is outside the 
scope of the present document), the program is executed by 
a compiled program executer (not shown). 

The class loader is also invoked whenever an executing 
bytecode program encounters a call to an object method for 

30 an object class that has not yet been loaded into the user's 
address space. Once again the class loader 116 loads in the 
appropriate object class and calls the bytecode program 
verifier 112 to verify the integrity of all the bytecode 
programs in the loaded object class. In many situations the 

35 object class will be loaded from a remotely located 
computer, such as one of the servers 104 shown in FIG. 1. 
If all the methods in the loaded object class are successfully 
verified, an object instance of the object class is generated, 
and the bytecode interpreter 114 is invoked to execute the 

40 called object method. 

Synchronized methods arc defined for the purposes of this 
document to be methods that include using a locking meth- 
odology so as to limit the number of threads of execution 
(hereinafter 4 'threads") that can simultaneously use a system 

45 resource. The most common synchronization tool is a 
mutex. which enables only a single thread to use a particular 
system resource at any one time, and which includes a 
mechanism for keeping track of threads of execution waiting 
to use the resource. While the synchronization mechanism 

50 described in this document is a mutex type of locking 
mechanism, the methodology of the present invention is 
equally applicable to computers system having other syn- 
chronization mechanisms, including but not limited to 
semaphores, time based lock expirations, and so on. 

55 In the context of the preferred embodiment, a syn 
nized method is always synchronized on a specific object 
For example, multiple threads may execute synchronized 
methods that call for exclusive use of a system resource 
represented by a specific object. When any one of the threads 

60 has ''possession" of the lock on the object, all other threads 
that request possession of the lock on the object are forced 
to wait until all the earlier threads get and then release the 
lock on the object. 

Data Structures for Unlocked and Locked Objects 

CO 

FIG. 2 shows the data structure 200 in a preferred 
embodiment of the present invention for an object that has 
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not been recently locked. As will be described next, all such allocated lock data subairay has a specific VFT (VFT, A-01 ) 

objects are, necessarily, unlocked and furthermore have not 250 that includes: (A) pointers 212 to each of the methods 

been allocated a lock data subarray. In one preferred 214 of the object class; (B) a pointer 256 to a local 

embodinient. the phrase "object X has not been recently object-specific locking procedure (Local Lock2) 260 used 

locked* is defined to mean that object X has not been locked 5 for synchronizing an object to a thread; (C) a pointer 217 to 

since the last garbage collection cycle by the operating a special Class Object 218; and (D) a pointer 220 to an 

system. In other preferred embodiments, the term "recently" unlock method for releasing the lock monitor There is one 

may be defined as a predefined amount of time, such as a Class Object 218 for each defined object class, and the Class 

certain number of seconds, or as the period of time since a Object includes a permanently allocated lock data subarray 

dependable periodic event in the computer system other than 10 (otherwise referred to as a lock monitor) 219. 

the execution of the garbage collection procedure. Local object- specific locking procedure 260 is used to 

An object of object class A has an object handle 202 that service lock requests on objects that are locked and objects 

includes a pointer 204 to the methods for the object and a that have recently been locked. The local object-specific 

pointer 206 to a data array 208 for the object locking procedure 260 includes as private data a lock data 

The pointer 204 to the object's methods is actually an 15 subarray 249 for storing lock data. The local object-specific 

indirect pointer to the methods of the associated object class. locking procedure has instructions for updating that object's 

More particularly, the method pointer 204 points to the stored lock data. More specifically, the local object-specific 

Virtual Function Table (VFT) 210 for the object's object locking procedure 260 has an object- specific locking method 

class. Each object class has a VFT 210 that includes: (A) (Local Lock2) for synchronizing the corresponding object to 

pointers 212 to each of the methods 214 of the object class; 20 a thread and for storing the corresponding lock information 

(B) a pointer 215 to a global lock method (Global Lockl) in the object's lock data subarray 249. 

- — 216 for synchronizing an object to a thread; (C) a pointer The lock data subarray 249 includes an object lock status 

217 to a special Class Object 218; and (D) a pointer 220 to indicator, a lock owner value, and a list header and list tail 

an unlock method 221 for releasing the lock monitors. There for a list of waiters (i.e., threads waiting to synchronize with 

is one Class Object 218 for each defined object class, and the 25 the object). In the preferred embodiment, the lock status 

Class Object includes a permanently allocated lock data indicator includes a first flag value (the Lock flag) that 

subarray (sometimes called a lock monitor) 219 for the class. indicates whether the object is locked or unlocked, and a 

VjB* e Class Object 218 is used in the preferred embodiment second flag value (the NotRecentlyLocked flag) that indi- 

to synchronize access to the lock data subarrays of all cates whether or not the object has been recently locked. The 

objects that are instances of the corresponding object class. 30 NotRecentlyLocked flag is set (to True) if the object has not 

As shown in FIG. 2, there is only one copy of the VFT 210 been recently locked. In the preferred embodiment the 

and the object methods 214 for the entire object class A, NotRecentlyLocked flag is set by the Lock Data QeanUp 

regardless of how many objects of object class A may exist method, and is cleared by the Global Lockl and Local 

Furthermore, the global lock method (Global Lockl) 216 Lock2 methods, 

and the Unlock method 221 are methods of the 4 *Object M 35 

object class, which is the object class at the top of the object ^ L^ 0 * Methodology 

class hierarchy in the preferred embodiment. Each computer system, such as a client computer 102. has 

The Global Lockl method 216 is used to handle requests many objects, each having an associated object class. Every 

by threads to synchronize with an object that has not yet ^ object is said to be an instance of its associated object class, 

been allocated a lock data subarray. The unlock method 221 Each object class inherits properties from its superclass, and 

is used to handle requests by threads to desynchronize with every object class is a subclass of a top level object class 

an object The unlock method 221 is conventional in called the "Object" object class. 

operation, removing the current owner of a specified object* s For each object class mat exists in a particular address 
monitor, setting the lock status to unlocked if there are no 45 space, there is a virtual function table (VFT) that contains a 
threads waiting on the specified object's monitor, and otb- list of all the methods (i.e.. executable procedures) associ- 
erwise making the topmost waiting thread the owner of the ated with the object class as well as a pointer to each of those 
specified object's monitor while leaving the lock status as methods. As shown in FIG. 2. the VFT for each object class 
\locked. also includes a reference to the Global Lockl method, which 
FIG. 2 also shows that the "Object" object class also 50 in the preferred embodiment is a method associated with the 
includes a second lock method 222, called the Lock Data "Object" object class. Whenever an object has not been 
CleanUp method for reclaiming the lock data subarray from allocated a Lock data subarray, its method pointer points to 
an object. It should be pointed out that the three Lock the default VFT for the object's object class, 
methods 216, 221, and 222 could be implemented as the In accordance with a first preferred ernbodiment of the 
methods of any object class known to be available in all 53 present invention, each object class has an associated virtual 
systems using the methodology of the present invention, and function table mentioned above as the first VFT. and some- 
do not need to be part of the "Object" object class. times herein referred to as "the primary VFT." Further, for 
FIG. 3 shows the data structure 240 for a locked object in each object that has been recently locked, the system creates 
a preferred embodiment of the present invention. This is also an object- specific virtual function table (VFT). The object- 
the data structure for any object that has recently been 60 specific VFT references a local lock method. Local Lock2 
locked, and thus has been allocated a lock data subarray. A 260, that is different from the global lock method. Global 
locked object of object class A has an object handle 242 that Lockl 216. referenced by the primary VFT. 
includes a pointer 244 to the methods for the object and a Tables 1. 2, 3 and 4 contain pseudocode representations of 
pointer 246 to a data array 208 for the object. the Global Lockl, Local Lock2. and Lock Data Cleanup 
The method pointer 244 of an object that has recently 65 software routines relevant to the present invention, The 
been locked points to a object-specific version of the Virtual pseudocode used in these appendices utilizes universal corn- 
Function Table 250 (VFT. A-01). Each object that has an puter language conventions. While the pseudocode 
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employed here has been invented solely for the purposes of the object is already locked then the thread is added to the 

this description, it is designed to be easily understandable by waiting thread list for the object Otherwise, if the object is 

any computer programmer skilled in the ait. unlocked, the requesting thread becomes the lock owner and 

' c . \Jl A . . . . . , the lock status is changed to locked. 

Referring to FIG 4 and Uje pseudocode for the Global met hod 221 processes requests to release the 

Ux±l method 216 shown in Table 1, when an object that has * jnev ^ s ^ ^ 

not been allocated a lock data subarray is the subject of a ^ waiti y ttM Ust is ^ ±t lock 0 * ne * md b 

synchronized method call, the global lock method (Globd allowcd t0 rcsumc execution. If there are no waiting threads, 

Lockl) associated with the object is invoked. The Global ^ ^ lock smu& b updated to Unlocked", which in some 

Lockl method begins by requesting and waiting for a lock implementations may be indicated simply by the Lock 

on the Class Object associated with the object to be locked i° Gwner datum cnangea - to a DU u value and the Lock 

(step 270). The remainder of the Global Lockl method is not status fl ag reset t0 False. 

executed until the thread making the Global Lockl method ^ Lock2 handles all synchronization requests on 
call obtains a lock on the Class Object. mc object, even after the object becomes unlocked, until the 
The Global Lockl and Lock Data CleanUp methods need object's lock data subairay is deallocated by the Lock- 
to be synchronized, by acquiring a lock on the Class Object, 15 CleanUp method. 

to prevent against corruption due to concurrency. For FIG. 6 depicts a first preferred embodiment for the lock 

example, in a multiprocessor system, the Global Lockl data cleanup method which releases the storage for the 

procedure could be simultaneously invoked by two proces- object-specific VFT and the object-specific locking proce- 

sors on the same object at the same time. Unless precautions dure. This embodiment is used in environments where the 

are taken, this could result in the creation of the object- lock data cleanup method does not require synchronization 

specific VFTs and two object-specific local Lock2 proce- with other concurrent thread activity. Referring to FIG. 6 and 

dures. To solve this problem it is necessary in the Global the pseudocode for the Lock Data CleanUp method 222 

Lockl and the Lock Data CleanUp procedures to lock the shown in Table 3, in a preferred embodiment the Lock Data 

Class Object for the type of a specified object while rear- CleanUp method is called by the garbage collection proce- 

ranging the specified object's internal data structure. dure to check all objects with allocated lock data subarrays 

After obtaining a lock on the Class Object, a check is each time execution of the garbage collection procedure is 

made as to whether the object is locked (or recently locked) initiated. Alternately, the Lock Data CleanUp method is 

or unlocked (or recently unlocked). Whether the object is called by the garbage collection procedure to check all 

locked or not can be ascertained by checking for the exist- ^ objects each time execution of the garbage collection pro- 

ence of an object-specific locking procedure and an object- cedure is initiated, 

specific VFT (step 271), In the situation where the object- In the preferred embodiment of the present invention, if 

specific locking procedure and the object-specific VFT exist any object's lock data subarray remains unused for the 

the method proceeds to step 276. Otherwise, the Global period of time between two garbage collection cycles, that 

Lock! method creates a local object-specific locking proce- 35 object is considered to not have been recently locked. More 

dure that includes as private data a local lock data subarray specifically, if an object's NotRecentlyLocked flag is set to 

(step 272). Global Lock 1 also initializes the local lock data True by the Lock Data CleanUp procedure during one 

subarray by storing data representing the identity of the local garbage collection cycle, and remains true at the next 

owner thread in the lock data subarray and by clearing the garbage collection cycle, then the lock data subarray 

NotRccentlyLocked flag. Additionally, the Global Local ^ (actually the object-specific VFT and object-specific local 

method creates an object-specific VFT for mis object that lock procedure) for that object is released, 

references the object-specific locking procedure (step 272). The Lock Data CleanUp procedure begins by determining 

Next, the method pointer of the object is altered to point to if me object specified by the calling procedure (e.g.. the 

the object-specific VFT. Further, the lock on the Class garbage collection procedure) has a local object-specific 

Object is released (step 276). Lastly, the local locking 4J locking procedure (step 302). The existence of the local 

method. Local Lock2, is invoked (step 278). Due to the object-specific locking procedure indicates mat there is 

alteration of the object's method pointer and the creation of storage that may need to be reclaimed, otherwise the pro- 

the object-specific VFT. the Local Lock2 method will auto- cedure returns. Next the procedure determines whether the 

matically be invoked to handle subsequent synchronization specified object is locked or whether the object has at least 

requests on this object one waiting thread (step 304). These conditions indicate that 

Referring to FIG. 5 and the pseudocode for the Local the storage allocated for the object-specific locking proce- 

Lock2 method 260 shown in Table 2. the Local Lock2 dure and VFT need not be reclaimed at this time since there 

method simply performs normal servicing of the received still exists a need for their use. In this case (step 304- Y). the 

synchronization request which includes normal updating of method returns. 

the lock data (step 290). In addition, any call to the Local 55 Otherwise, a further check is made to determine whether 

Lock2 method causes the specified object's NotRecenUy- the object has been recently locked (step 306). In the 

Locked flag to be cleared (step 300). In an alternate preferred embodiment, an object is considered not to have 

embodiment, the specified object's NotRccentlyLocked flag been recently locked if the NotRccentlyLocked flag in its 

is cleared only if the object has a lock status of Locked after lock data subarray is set to True. An object is considered to 

the synchronization request has been processed. The Local ^ have been recently locked if it has a lock data subarray and 

Lock2 method is so simple because it is known that when- the NotRccentlyLocked flag is set to False (i.e., the flag is 

ever the Local Lock2 method is called, the specified object not set). 

(Le., the subject of the lock processing) already has a lock if the object has been locked recently, the NotRecently- 

data subairay. Locked flag for the objects is set to True (step 308) and the 

^~For normal mutcx operation, if the lock handling request 65 procedure returns. Step 308 prepares the object's lock data 

(i e the request being handled by the Local Lock2 method) subarray for release during the next garbage collection cycle 
is by a thread to synchronize with the associated object, if if ate lock data subarray remains unused during that time. 



02/04/2004, EAST Version: 1.4.1 



5/761,670 

9 10 

If the object has not been locked recently, the storage method releases the storage previously allocated for the 

allocated for the local object- specific locking procedure and object-specific VFT and the object-specific locking proce- 

for the object- specific VFT is released (step 310). Lastly, the dure (416). Next, the method pointer of the object for the 

method pointer of the object is set to the primary VFT for the object is set to the primary VFT for the object* s class object 

object's class object (step 312). 5 ( s tep 418). Lastly, the lock on the object's class object is 

FIG. 7 depicts an alternate embodiment of the lock data released (step 420). 

cleanup procedure. In the alternate embodiment, the lock described methodology, objects that are 

data cleanup procedure executes concurrently with , otficr * £ ^ 

thread locking activities thereby requiring the lock data " , . "y " . * . . . . rr J 

deanupprociuretobesyncr^onizedwith Lse concurrent to locking Only objects that are locked have memory space 

processes. Referring to FIG. 7 and the pseudocode for the allocated to store lock data. 

Lock Data QeanUp method 222 shown in Table 4, the Lock While the present invention has been described with 

Data CleanUp method is called by the garbage collection rc f ererjC e to a few specific embodiments, the description is 

procedure to check all objects with allocated lock data illustrative of the invention and is not to be construed as 

subarrays each time execution of the garbage collection i* ^ling the invention. Various modifications may occur to 

procedure is initiated. Alternately, the Lock Data CleanUp ^ smed ^ tf)c m wjthout dcparting from ^ true spirit 

method is called by the garbage collection procedure to ^ of ^ invenUon M deftned b the ^cd 

check all objects each time execution of the garbage col- C ] a i ms 
lection procedure is initiated. 

The Lock Data CleanUp procedure begins by deterrnining 20 For instance, other mechanisms than the NotRecently- X 

if the object specified by the calling procedure (e.g M the Locked flag could be used to determine whether an object | 

garbage collection procedure) has a local object-specific has been recently locked For example, a timestamp could be I 

locking procedure (step 402). The existence of the local stored in the lock data subarray of unlocked objects at the / I r i 

object-specific locking procedure indicates that there is time they are unlocked, and that timestamp could be checked I T {/rts£dnp*$ 

previously allocated storage that may need to be reclaimed. 25 by the Lock Data CleanUp procedure. If the timestamp 1 

If none exists (step 402-N). the procedure returns. Next, the represents a time more than a threshold amount of time in ) 

procedure determines whether the specified object is locked the past the object would be determined to not have been-^ 

or whether the object has at least one waiting thread (step recently locked. 

404). These conditions indicate that the storage allocated for ^ Whfle the lock ^ subOTay described above is suitable 

the object-specific locking procedure and VFT need not be fw i™^^ a mutc ^ th c samc lock data subarray 

reclaimed at this time since there still exists a need for their and release methodology and mechanism could be 

use. In this situation (step 404- Y), the procedure returns, A used t0 aUocate ^ fclcasc morc ^mptex lock data 

further check is made to determine whether the object has structures< such ^ those for semaphores and those for 

been recently locked (step 406). In thc preferred monitoTS ^ handlc waits on notification events, 
embodiment, an object is considered not to have been 

recently locked if the NotRecentlyLocked flag in its lock Further, the method and system described hereinabove is 

data subarray is set to True. An object is considered to have amenable for execution on various types of executable 

been recently locked if it has a lock data subarray and the mediums other than a memory device such as a random 

NotRecentlyLocked flag is set to False (,Le. the flag is not access memory. Other types of executable mediums can be 

set). 40 used, such as but not limited to. a computer readable storage 

If the object has been locked recently, the NotRecently- medium which can be any memory device, compact disc, or 

Locked flag for the object is set to True (step 408) and the flo IW disk, 
procedure returns. Step 408 prepares the object's lock data 

subarray for release during the next garbage collection cycle 45 TABLE 1 

if the lock data subarray remained unused during that time. pseudocode representation of global locki method 

Next, the Lock Data CleanUp method requires synchro- — ^ — - — — - — — ^— — — 

nization with other concurrently running threads employing T^^T^ 

locking activity. This synchronization is achieved by the ^ Object axg the ob^Ho be locked / 

method requ esting and waiting for a lock on the Gass Object 50 /* Acquire lock to ensure that multiple threads do not by to I 

associated with object to be locked (step 412). The remain- process the object ai the same hem •/ 

der of the Lock Data CleanUp method is not executed until ^ ^^J^l^^^T' * CUM(0 * ct) * 

the thread making the Lock Data CleanUp method call ff ^ ^j^^ wl havc an object-specific Virtual Function Tabic and 

obtains a lock on the Class Object an object-specific locking procedure 

Once the lock on the Class Object has been obtained, thc 55 {Create a toe* object^c, ^* ^^J^^^ 

v*, , " . . J . , _ 4. includes as private data, a lock data subarray for this 

Lock Data QeanUp method once again checks to see if the * 

lock has been recently locked by examining whether the create an object-specific virtual Fuwtion Table for this 

NotRecentlyLocked flag is set (step 414). Note that it is object that references flic local, objcci^pecific, object 

^ssiblethatano^ o^SS^^SS^ * »fe 

the calling thread was waiting for a lock on the Class Object 60 object.speciflc VFT tor the Object. 

In that case, it would be improper to deallocate the specified } 

object's lock data subarray, and that is why a second check Release lock on ctoss Object. 

(414) on the NotRecentlyLocked flag of the specified object *voke %£ c ?^^ ific ' ^ proccdurt refcrenced * 

is necessary. If the NotRecenUyLocked flag is not set Retum ol *** s 

(414-N). the Lock Data CleanUp method releases the lock 65 } 

on the class object (step 420) and returns. If the NotRecent- — ^ — — — — — 
lyLocked flag is still set (414-Y). the Lock Data QeanUp 
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TABLE 2 
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Lock Command. 
Clear Object's NotRcocntlyLocl«d Flag. 

Return 




rAm^fo^tingaco^ter systenu co^g 

and unlocked, each stored object including a 
pointer to a data structure ; 

and 



20 



Set NotRccaittybockcd flag to Twe 
Return 

the Object Class 




p^cedure: Uc^t^CkanUtfObject) 



45 



( Return ) 
If Object has been recently J^**? T1fr _w w kxk data 

NotReccnOyLockcd flag = T** 
Return 

Rebeck ** 

U Object to «* bc«o locteJ """^ ^ 

collection cycle) 

* 1 1„ Ww-*L obiect-jpecific, object locking 

tbe Object Class 

Release kock onCUssObject 
Return 
> 



object's local object locking procedure. 

locking procedure. 
\ The method of claim 1, 

service a lock request ™ <m . 1 1 said 

locking procedure. 
4. The method of claim 3. 

object locking procedure. 



55 



60 



65 
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S said local VFT for the specified object. 
6. The method of claim 1. 

a* tod** pointers referencing a set of 

SSfLd-e* with said i: 

pointer that references said global object toccng P 

JotktL with each of said stored objects that has never 
tSSwi of looted a methods pointer that u 

SrenSsaMp^ 
, rl^-JS* objects that has a lock status of 

said local object locking procedure; ana 

7 The method of claim 1, 
whTn e^Lg said lock data cleanup J?***"- 

said specified object 

8 A computer system, comprising: . , ifv 

defined release criteria are satisfied; 

^3 a lock data subarray. uses said local object 

S£ deanup procedure to release a specified object s 
local object locking procedure. 
9 The computer system of claim 1. 

-less- 

Ces said local object locking procedure. 
10. The computer system of claim 8, 



30 



35 



procedure; . kstaUsof locke d including 

ESS. said local object locking procedure. 

Vaid global object locking procedure. 
12 The computer system of claim 8. 

wtpri a local virtual function table (VFT) tnai 

l/The^computcr system of claim 13. 
SSSKd-t VFT for the object class corre- 
JLesTw^being executed on a data processing 
in said memory, each stored ofcjea nav g 
a data structure stored in said medium; 



45 



50 



55 
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a global object locking procedure ^%*°2£*Z 
for changing a ^ »£^^£3Se 
,o locked, for creating a local object locKWgJ^ 
for said specified untocked . <*gL «£ %£*/f* 5 

mA^a rei M se criteria arc satisfied* 



10 



Object's lOCW UUjcvi e r- 

defiaed release critena are sausficd^ 

J^TEct which has never had a lock status of 

procedure, , ct a ms of locked including 

each stored *J^ taw * al ^n^ «U«s that 
n mpt hods do inter to a subset of saia proccuut^ 
^SSMS object locking procedure; and 

Kdes JS ; W^£25SS5"d-- W- 

set of object cl ass es •^^^aSTtaJte 
primary virtual fanct.cn JJj^J^ wim 
pointers referencing a set ot rnejnoui 
laid object class as well as a pointer that references saio 
global object locking procedure; 53 

procedure; and including instruc- 

SSLft reS said local VFT for me specified 

object. 



20 The computer readable storage medium of claim IS. 

referencing a set of methods assayed w*h 
Sdobject class as weUasapointa that references said 

global object locking procedure; 
each of said stored objects that has never b£**££ 
of locked including a methods pointer that references 
said primary VFT for a corresponding one of said 
object classes; 
for each of said stored objects that has 
iocked storing in said computer ^"U^ 
me dium, a local virtua! 

includes pointers referencing said local object g 
pfeltf to rrfneotc s>»l loc* VFT W Be >P«» 

S£^.aJwViT<« «»<««» *« 

storing lock data and instructions tor upoauus 
specified object's stored lock date; and 
a lock data cleanup procedure for releasing a spewed 
25. local object locking precede when pre- 
defined release criteria are satisfied; 
wherein said other data f^^^M c£ 

23 Erf of computer-readable modules of claun 22. 

pTte " £X a subseTof said procedures that 
£2, said local object locking procedure; and 
.° k ^ dcanup procedure including instructions 

global object locking procedure. 
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